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(57) The present invention provides, in a preferred 
embodiment, a method whereby resynchronization 
between a transmitter and receiver is activated intui- 
tively by, and transparently to, an authorized user, 
including: transmitting at least a first message from the 
transmitter to the receiver; and, in response to the 



receiver receiving the first message, the receiver detect- 
ing the absence of synchronization between the trans- 
mitter and the receiver and performing a resynchroniz- 
ation procedure to restore synchronization between the 
transmitter and the receiver. 
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Description 

Technical Field 

The present invention relates to keyless entry sys- 
tems generally and, more particularly, but not by way of 
limitation, to a novel method of recovering synchroniza- 
tion between a transmitter and a receiver of a keyless 
entry system. 

Background of the Invention 

Current remote keyless entry systems that employ 
rolling code algorithms occasionally require ^synchro- 
nization of receiver to transmitter. For instance, chang- 
ing the transmitter battery, occurrence of a noise spike 
when writing to receiver's EEPROM, or when pressing 
the transmitter button(s) too many times while outside 
the range of the receiver may cause the system to lose 
synchronization. Once synchronization is lost, the sys- 
tem does not respond and appears inoperative. Resyn- 
chronization is required to restore the system operation 
to normal. Current systems require a manual sequence 
of operations for restoring synchronization, such as 
depressing lock and unlock buttons for a predetermined 
period of time and waiting for a lock cycle feedback. 
This manual operation can be confusing, and if the 
operator does not know the procedure, the operator 
may bring the keyless entry system in for service. This 
leads to customer dissatisfaction and high warranty cost 
for the manufacturer, e.g., a vehicle manufacture. 

One method to eliminate the manual ^synchroni- 
zation is by using non-volatile memory in the transmit- 
ter. In this circumstance it is assumed that the 
transmitter sequence number will never be below the 
receiver's sequence number, and therefore manual 
resynchronization would not be required. A further 
assumption is that data written and stored in the trans- 
mitter's EEPROM will always be valid. However, this 
method comes with many shortfalls. One is cost EEP- 
ROM is relatively expensive, and packaging external 
EEPROM in the transmitter can be difficult, if not impos- 
sible, on some applications requiring minimum layout 
area. With EEPROM, complex program routines are 
required to guarantee that the data written is truly valid, 
otherwise complete reprogramming of the system will 
be necessary to recover normal operation. This is time 
consuming and is a great inconvenience to the end 
user. The factors of cost, packaging, EEPROM reliabil- 
ity, and increase in code see dictate that using EEP- 
ROM in the transmitter is not a reliable nor viable 
method for keeping the system in synchronization. What 
is needed, but heretofore has been unavailable, is a 
method whereby resynchronization is activated intui- 
tively by. and transparently to. the operator. Such a 
method should also permit that the entire resynchroni- 
zation process be implemented only in the receiver 
without need for the transmitter to store any special 



resynchronization commands, nor execute any special 
program routines to recover synchronization. Addition- 
ally, a method is needed whereby the authorized user is 
not expected to learn any complicated resynchroniza- 

5 tion procedures. 

Accordingly, it is a principal object of the present 
invention to provide a method for restoring synchroniza- 
tion between a transmitter and receiver without the use 
of special manual resynchronization procedures. 

w A further object of the present invention is to reduce 
costs by eliminating EEPROM in the transmitter. 

An additional object of the present invention is to 
reduce the RF design of the transmitter by eliminating 
external EEPROM in the transmitter. 

15 It is yet a further object of the present invention to 
eliminate special EEPROM validation program routines 
in the transmitter and receiver. 

It is yet an additional object of the present invention 
to maintain the security level between transmitter and 

20 receiver. 

It is yet another object of the present invention to 
provide more packaging flexibility of the system by elim- 
inating the need for external EEPROM in the transmit- 
ter. 

25 Other objects of the present invention, as well as 
particular features, elements, and advantages thereof, 
will be elucidated in. or be apparent from, the following 
description and the accompanying drawing figures. 

30 Summary of the Invention 

The present invention achieves the above objects, 
among others, by providing, in a preferred embodiment, 
a method whereby resynchronization between a trans- 

35 mitter and receiver is activated intuitively by, and trans- 
parently to, an authorized user, said method 
comprising: transmitting at least a first message from 
said transmitter to said receiver; and in response to said 
receiver receiving said first message, said receiver per- 

40 forming a resynchronization procedure to restore said 
synchronization between said transmitter and said 
receiver. 

Brief Description of the Drawings 

45 

Understanding of the present invention and the var- 
ious aspects thereof will be facilitated by reference to 
the accompanying drawing figures, submitted for pur- 
poses of illustration only and not intended to define the 
so scope of the invention, on which: 

Figure 1 is a pictorial diagram of the system of the 
present invention. 

Figure 2 is a representation of the message struc- 
55 ture for normal messages used in conjunction with 
the system of the present invention. 
Figure 3 is a representation of the areas within a 
cryptographic key space of the message structure 
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where synchronization can be lost. 
Figure 4 is a block diagram of the variable key press 
memory map of the system of the present inven- 
tion. 

Figures 5a and 5b comprise a flow diagram of the 5 
resynchronization process. 
Figures 6a and 6b comprise a flow diagram of the 
resynchronization process algorithm. 

Description of the Preferr ed Embodiment w 

Reference should now be made to the drawing fig- 
ures on which similar or identical elements are given 
consistent identifying numerals throughout the various 
figures thereof, and on which parenthetical references 75 
to figure numbers direct the reader to the view(s) on 
which the elemerrt(s) being described is (are) best 
seen, although the element(s) may be seen also on 
other views. 

Figure 1 shows the elements associated with the 20 
system of the present invention. A remote keyless entry 
system, generally indicated by reference numeral 10, 
which includes a transmitter 12 used by an authorized 
user to transmit a desired function (e.g.. door lock, door 
unlock, panic) and a receiver 1 8 located within a vehicle 25 
or structure for which keyless entry is desired. Transmit- 
ter 12 emits RF signals 16 in response to use activation 
of one or more buttons 14 associated with transmitter 
12. Receiver 18 periodically checks for the presence of 
a transmission and performs the requested function 30 
only if the fields within message structure 20 (Figure 2) 
are intended for that particular receiver and contains 
valid security information. 

As is described in detail below, the present inven- 
tion establishes a resynchronisation process under cir- 35 
cumstances whereby pressing button 14 causes 
transmitter 12 to emit RF signals 16 which are, in turn, 
received by receiver 18 and do not match stored values 
in the receiver such that message 20 is not authenti- 
cated and the receiver fails to execute function code 24. 40 
Under these circumstances, receiver 18 establishes 
one of a set of resynchronization processes, which may 
require pressing button 14 additional times, as can be 
understood to be a perfectly intuitive reaction to an 
apparent initial failure of function 24 to be executed. 45 

Reference should now be made to Figure 2. Mes- 
sage structure 20 is transmitted for normal functions 
(e.g., door lock, door unlock, panic) upon depressing 
one or more buttons 14 of transmitter 12. Message 
structure 20 provides for dynamic security encoding to so 
prevent the recording and subsequent playback of oth- 
erwise legitimate messages and to prevent receiver 18 
from being deceived into accepting messages from 
unauthorized sources. Once transmitter 12 is manufac- 
tured it is programmed with a transmitter ID 26, an initial 55 
first sequence number value (SQN1) 28, a random ini- 
tial state (not shown), and a cryptographic key (not 
shown). Transmitter ID 26 is a unique binary number 



associated with each individual transmitter 12, as is the 
random initial state, whereas the cryptographic key may 
be common to all transmitters. The random initial state 
is used as a starting point from which an authentication 
code is advanced with each message 20 transmission. 
SQN1 28 also advances with each message 20 trans- 
mission to indicate the required number of advances 
that receiver 18 must perform to cryptographically syn- 
chronize with the transmission. Message 20 comprises 
preamble 22 which indicates the start of a message, 
function code 24 which identifies the function being 
requested, transmitter ID 26, SQN1 28 which is used to 
synchronize transmitter 12 and receiver 18 to account 
for situations in which messages are received in error 
due to RF noise, or transmitter 12 is operated beyond 
the range of receiver 1 8, or when the battery of transmit- 
ter 12 is replaced, authenticator 30 which is a calcula- 
tion using an algorithm to combine a cryptographic key 
with function code 24 and CRC 32 which is a cyclic 
redundancy check code to permit receiver 1 8 to validate 
the integrity of message transmission. Message struc- 
ture 20 provides for system security by preventing the 
deception of receiver 18 by interception, recording, and 
subsequent playback of RF signals 16 since SQN1 28 is 
advanced with each transmission; therefore, a recorded 
message 20 when played back will have an SQN1 28 
different than expected by receiver 1 8 and hence will fail 
synchronization verification and not be accepted. Mes- 
sage structure 20 provides additional system security 
by preventing the spoofing (emulation) of messages 
since modification of function code 24 (e.g., modifying 
lock command to unlock command) will cause receiver 
18 to calculate an incorrect authenticator 30. Since 
authenticator 30 is derived in part from a cryptographic 
key known only to transmitter 12 and receiver 18, unau- 
thorized parties cannot generate an authenticator 30 
that corresponds to function code 24 of their choosing 
and therefore message structure 20 cannot be artifi- 
cially constructed in a manner that would be acted upon 
by receiver 1 8. 

Reference should now be made to Figure 3 which 
shows the areas within the cryptographic key space 
where synchronization can be lost Sequence number 
line 40 shows four distinct resynchronization areas 
dependent on the values of SQN1 28 as received by 
receiver 18 and receiver second sequence number 
(SQN2) 42. If it is assumed, for purposes of illustration, 
that SQN1 28 comprises a 16-bit binary field then the 
maximum value of SQN1 28 is 2 16 or 65536. Receiver 
sequence number SQN2 42, which is stored in receiver 
18 and is equal to the most recently received and vali- 
dated SQN1 28, therefore could lie anywhere along 
sequence number line 40, having a value between 0 
and 65536. inclusive. It is when received SQN1 28 does 
not match an expected value based on SQN2 42 that 
synchronization between transmitter 12 and receiver 18 
is considered lost and resynchronization must occur. 

A first resynchronization process occurs within syn- 
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chronization window 44, a resynchronization area 
whereby, subsequent to a first message 20 reception, 
SQN1 28 received is greater than SQN2 42 by not more 
than K increments (i.e.. SQN1 28 < = SQN2 42 + K). In 
this case, receiver 18 will automatically advance SQN2 
42 to equal SQN1 28 and then authenticate message 
20. 

A second resynchronization process occurs within 
auto- resync window 48, a resynchronization area 
whereby, subsequent to a first message 20 reception, 
SQN1 28 received is less than or equal to a value of 16 
and is also less than SQN2 42 (i.e., SQN2 42 > SQN1 
28 < = 16), a condition generally occurring when trans- 
mitter battery changes are made and Random Access 
Memory is lost. In this case, receiver 18 will automati- 
cally advance SQN2 42 to equal SQN1 28 and then 
authenticate message 20. 

A third resynchronization process occurs in resyn- 
chronization area 50 whereby, subsequent to a first 
message 20 reception. SQN1 28 received is greater 
than SQN2 42 by more than K increments (i.e., SQN1 
28 > SQN2 + K). In this case, receiver 18 will execute a 
resynchronization process dependent upon receiving 
and verifying a second message 20 reception. 

A fourth resynchronization process occurs in resyn- 
chronization area 52 whereby, subsequent to a first 
message 20 reception, SQN1 28 received is greater 
than auto-resync window 48 yet less than SQN2 42. In 
this case, receiver 18 will execute a resynchronization 
process dependent upon receiving and verifying a sec- 
ond and a third message 20 reception. 

Reference should now be made to Figure 4 which 
shows a memory map of the system of the present 
invention, generally indicated by reference numeral 60. 
SQN history 62 FIFO memory is used by receiver 18 to 
dwarf attempts of recording three sequential messages 
in a row for purposes of playback attacks by maintaining 
a log of prior authenticated SQN1 28 values. Every time 
receiver 18 receives three or more sequential message 
20 transmissions containing the same transmitter ID 26 
and function code 24, it stores the most recently 
received SQN1 28 into SQN history 62 in a First- In- 
First-Out (FIFO) sequence. By increasing the number of 
SQN history 62 memory locations, the security of the 
system of the present invention is enhanced since the 
likelihood of matching the SQN1 28 of a received mes- 
sage 20 transmission to one previously transmitted is 
increased. Resynchronization processes 3 and four uti- 
lize message 20 transmissions with sequential SQN1 
28 values and identical function code 24 values which 
decreases the likelihood of unauthorized sources 
recording a possible resynchronization sequence of 
transmissions. In addition, use of this process 
decreases the amount of write cycles to non-volatile 
memory of receiver 18. thereby extending its life. 

Verification (VERF) 64 memory location provides 
for temporary storage of invalid SQN1 28 values and 
corresponding authenticator 30 values when SQN1 28 



values are in resynchronization areas 50 or 52. 
Receiver 18 stores successive SQN1 28 values and 
corresponding successive authenticator 30 values from 
a successive message 20 transmissions in a succes- 

5 sive VERF 64 locations, whereby a successive second 
message 20 transmission must occur for resynchroniza- 
tion area 50 and a second and a third successive mes- 
sage 20 transmission must occur for resynchronization 
area 52. If the successive message 20 transmissions 

w contain the same transmitter ID 26 and function code 
24, and SQN1 28 is sequential to the values stored in 
VERF 64 and there is not a match between most recent 
SQN1 28 and SQN1 28 values stored in SQN history 
62, then the successive transmissions of message 20 

75 are authenticated. It is preferred that the authentication 
process be performed after all requisite sequential 
transmissions of message 20 have been received in 
order to reduce latency time and reduce unnecessary 
computation. Upon successful authentication, function 

20 24 is executed and SQN1 28 from the most recent 
transmission is stored in SQN history 62. 

Memory location NSQN 66 is where most recently 
received SQN1 28 value is stored while message 20 
authentication process occurs. The value stored in 

25 NSQN 66 is compared to SQN2 42 to determine what 
level of resynchronization may be required. Subsequent 
to a successful message 20 authentication, memory 
location SQN2 42 is updated to contain the value of 
SQN1 28 stored in NSQN 66. Button number 67 mem- 

30 ory location is used to store function code 24 associated 
with a specific button 14 press of transmitter 12. Count 
68 memory location stores a value of how many succes- 
sive message 20 transmissions are required to achieve 
resynchronization. Press 69 memory location stores a 

35 value of how many successive message 20 transmis- 
sions have been received. 

Reference now to Figure 5 which shows a variable 
key press resynchronization flow chart comprising the 
following processes: 

40 

(a) Upon receipt of message 20 at step 70 as a 
result of one or more button 14 presses at transmit- 
ter 12, receiver 18 validates transmitter ID 26 at 
step 72 and then checks if NSQN 66 is valid, i.a, 

45 within sync window 44, at step 74. 

(b) If SQN1 28 value stored in NSQN 66 is valid, 
receiver 18 authenticates message 20, performs 
the function 24 at step 82, and checks count 68 
memory location to determine if three successive 

so message 20 transmissions have been authenti- 
cated in which case value of NSQN 66 is stored into 
SQN History 62 at step 86. 

(c) If at step 74, SQN1 28 value stored in NSQN 66 
is not validated to be within sync window 44. the 

55 value of NSQN 66 is checked to be within auto 
resynch window 48 at step 76 and if so. the value of 
NSQN 66 and authenticator 30 are stored in VERF 
64 memory location at step 78. 
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(d) At step 80, if the value of NSQN 66 is greater 
than synch window 44, and at step 88. if two suc- 
cessive message 20 transmissions have been 
received whereby press 69 memory location indi- 
cates 2 presses have been made of the same but- s 
ton 14 from button 67 memory location and 
whereby the value of NSQN 66 is sequential to 
value stored in VERF 64, and at step 90 the value 

of NSQN 66 does not compare with a value in SQN 
History 62, then at step 92 receiver 18 authenti- 10 
cates said two successive message 20 transmis- 
sions, performs function 24, and stores the value of 
NSQN 66 into SQN history 62 and into SQN2 42. 

(e) If two successive message 20 transmissions 
have not been received at step 88 or if a match is is 
determined between the value of NSQN 66 and a 
value in SQN History 62, then button 14 press is 
ignored at step 94 and receiver 18 awaits a new 
message 20 at step 70. 

(0 If a step 80, the value of NSQN 66 is not greater 20 
than sync window 44, then at step 96, if three suc- 
cessive message 20 transmissions have been 
received whereby press 69 memory location indi- 
cates 3 presses have been made of the same but- 
ton 1 4 from button 67 memory location and 25 
whereby the value of NSQN 66 is sequential to 
value stored in VERF 64, and at step 99 the value 
of NSQN 66 does not compare with a value in SQN 
History 62, then at step 100 receiver 18 authenti- 
cates said three successive message 20 transmis- 30 
sions, performs function 24, and stores the value of 
NSQN 66 into SQN history 62 and into SQN2 42. 

(g) If three successive message 20 transmissions 
have not been received at step 96 or if a match is 
determined between the value of NSQN 66 and a 35 
value in SQN History 62 at step 98, then button 14 
press is ignored at step 94 and receiver 18 awaits a 
new message 20 at step 70. 

Reference should now be made to Figure 6 
which shows a detailed variable key press resyn- 40 
chronization algorithm flow chart which comprises 
the following processes: 

(h) Upon receipt of Message 20 at step 70 as a 
result of a button 14 press of transmitter 12, 
receiver 1 8 checks for valid transmitter I D 26 at step 45 
72. If transmitter ID 26 is not valid, SQN2 42 is set 
equal to SQN1 28 as was stored in NSQN 66 at 
step 85 and receiver 18 awaits receipt of the next 
message 20 at step 70. 

(i) If step 72 is a valid transmitter ID 26, the value of so 
SQN1 28 as stored in NSQN 66 is checked to be 
within sync window 44 at step 110, and if yes, 
receiver 18 stores the value of NSQN 66 into SQN2 

42 at step 120, validates authenticator 30 at step 
134. performs function 24 at step 136. executes 55 
subroutine 124 to update button 67 and count 68 
memory location values, checks if count 68 value is 
now greater or equal to three at step 157 and if yes 



stores the value of NSQN 66 into SQN history 62 at 
step 152, otherwise if count 68 value is not greater 
than or equal to three at step 157, stores the value 
of NSQN 66 into SQN2 42 at step 85 and awaits 
next message 20 at step 70. 
(j) If at step 134, authenticator 30 is not validated, 
the value of NSQN 66 and authenticator 30 are 
stored in VERF 64 indexed with count 68 value, 
count 68 value is incremented by 1 at step 142, 
count 68 value is checked if greater or equal to 3 
and if yes authenticates all values stored in VERF 
64 at step 146, performs function 24 at step 148, 
sets count 68 value to 1 at step 154, stores the 
value of NSQN 66 into SQN2 42, and awaits next 
message 20 at step 70. 

(k) If at step 156 count 68 value is not greater than 
or equal to three, stores the value of NSQN 66 into 
SQN2 42 at step 85 and awaits next message 20 at 
step 70. 

(I) If at step 1 10, the value of NSQN 66 is not within 
synch window 44, then the value of NSQN 66 is 
checked at step 1 12 to be within auto resynch win- 
dow 48, and if yes, receiver 18 performs auto- 
resynch subroutine at step 132 (details not shown 
but which include store the value of NSQN 66 into 
SQN2 42, validate authenticator 30, perform func- 
tion 24, and await new message 20 transmission), 
(m) If, at step 112, the value of NSQN 66 is not in 
auto-resynch window 48, then at step 1 14 the value 
of NSQN 66 is checked if greater than SQN2 42 by 
K increments, and if yes, press 69 value is set equal 
to 2 at step 118, then subroutine 124 is executed to 
update button 67 and count 68 memory location 
values, then count 68 value is checked if equal to 
press 69 value at step 1 26 indicating that the requi- 
site number of successive message. 20 have been 
received and if yes checks that no duplicate values 
of NSQN 66 are stored in SQN history 62 at step 
128, authenticates all values stored in VERF 64 at 
step 146. performs function 24 at step 148, sets 
count 68 value to 1 at step 154, stores the value of 
NSQN 66 into SQN2 42, and awaits next message 
20 at step 70. 

(n) If count 68 value is not equal press 69 value at 
step 126, the value of NSQN 66 and authenticator 
30 are stored in VERF 64 indexed with count 68 
value, the value of SQN1 as stored in NSQN 66 is 
stored into SQN2 42 at step 85 and receiver 18 
awaits next message 20 transmission at step 70. 
(o) If the value of NSQN 66 is greater than SQN2 42 
+ K at step 114, then press 69 value is set to three, 
subroutine 124 is executed to update button 67 and 
count 68 memory location values, then count 68 
value is checked if equal to press 69 value at step 
126 indicating whether or not the requisite number 
of successive message 20 have been received, the 
flow is the same as previously identified for step 
126 onward. 



5 



BNSDOCID: <EP. 



0857842A2_I_> 



9 



EP 0 857 842 A2 



10 



Reference should now be made to Figure 7, 
variable key press resynchronization subroutine 
124 which comprises the following processes. This 
subroutine determines if successively received 
function 24 codes (shown in flow chart as N button 
#) are identical and correspondingly if successively 
received NSQN 66 values are sequential (i.e., the 
value of NSQN 66 = SQN2 42 + 1) both of which 
are necessary during resynchronization to permit 
message 20 authentication, 
(p) If successive function 24 codes are equal at 
step 138, and the value of NSQN 66 is equal SQN2 
+ 1 at step 140. then count 68 is incremented by 1 
and subroutine returns to resynchronization pro- 
gram where it initially exited, 
(q) If successive function codes are not equal at 
step 138, button # 67 value is set equal to the most 
recent received function 24 at step 150, count 68 is 
set at 1 at step 144, and subroutine 124 returns to 
the program where it initially exited, 
(r) If successive NSQN 66 values are not sequential 
at step 140 count 68 is set to 1 and subroutine 124 
returns to where it initially exited. 

It will thus be seen that the objects set forth above, 
among those elucidated in. or made apparent from, the 
preceding description, are efficiently attained and. since 
certain changes may be made in the above method 
without departing from the scope of the invention, it is 
intended that all matter contained in the above descrip- 
tion or shown on the accompanying drawing figures 
shall be interpreted as illustrative only and not in a limit- 
ing sense. 

It is also to be understood that the following claims 
are intended to cover all of the generic and specific fea- 
tures of the invention herein described and all state- 
ments of the scope of the invention which, as a matter 
of language, might be said to fall therebetween. 

Claims 

1 . A method for restoring synchronization between a 
transmitter and a receiver comprising: 

(a) transmitting at least a first message from 
said 

(b) in response to said receiver receiving said 
at least said first message, said receiver 
detecting the absence of synchronization 
between said transmitter and said receiver and 
performing a resynchronization procedure to 
restore synchronization between said transmit- 
ter and said receiver. 

2. A method, as defined in Claim 1 . whereby: said first 
message comprises message elements including a 
preamble, a transmitter ID, a first function code, a 
first sequence number, an authenticator code, and 



a CRC code. 

3. A method, as defined in Claim 2, whereby: said 
transmitter ID is a unique binary value common for 

5 said transmitter and said receiver. 

4. A method, as defined in Claim 2, whereby: said first 
function code is a binary value derived from a but- 
ton depression of said transmitter. 

10 

5. A method, as defined in Claim 2, whereby: said first 
sequence number is a 16 bit binary which is incre- 
mented for each said first message by a program 
algorithm. 

15 

6. A method, as defined in Claim 2, whereby: said 
authenticator code is a binary value algorithmically 
derived based on a cryptographic key contained 
within said transmitter and said receiver. 

20 

7. A method, as defined in Claim 2, whereby: said 
CRC is a binary value algorithmically calculated 
from said binary values of other said elements of 
said first message. 

25 

8. A method, as defined in Claim 1, whereby: said 
receiving said first message includes parsing said 
first message into message elements. 

30 9. A method, as defined in Claim 8, whereby: selected 
said message elements are stored in said receiver 
as synchronizing parameters which include a sec- 
ond sequence number, a second function code, a 
message count value, a message number value, a 

35 sequence number history memory, and first, sec- 
ond, and third message verification values. 

10. A method, as defined in Claim 1. whereby: said 
resynchronization procedure includes validating 
40 said transmitter ID. determining one of first, second, 
third, or fourth resynchronization levels, and estab- 
lishing one of first, second, third, or fourth resyn- 
chronization processes. 

45 11. A method, as defined in Claim 10, whereby: said 
transmitter ID is compared with said second trans- 
mitter ID such that a comparison match permits 
continued processing of said first message. 

so 12. A method, as defined in Claim 10, whereby: estab- 
lishing said first resynchronization process results 
from comparing said first sequence number with 
said second sequence number stored in said 
receiver and determining that a relationship exists 

55 according to the following equation: 

SQN2 < SQN1 < = SQN2 + K 
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where 

SQN1 is said first sequence number, 
SQN2 is said second sequence number, and 
K is a binary constant. 5 

13. A method, as defined in Claim 12, whereby: said 
first resynchronization process comprises: 

(a) storing said first sequence number into 10 
memory location of said second sequence 
number, checking for valid said authenticator 
whereby if valid go to step 

(b) , otherwise if not valid, store said first 
sequencenumber and said authenticator value 15 
in said verification memory indexed by said 
count value, increment said count value by 1 , 
check if said count value is greater or equal to 

3 and if so authenticate all said verification 
memory values, performing said function, set- 20 
ting said count value equal 1 , setting said sec- 
ond sequence number value equal to said first 
sequence number value and await a subse- 
quent message; 

(c) comparing said first function code with said 25 
stored second function code, whereby if not 
equal store said first function code value into 
said second function code memory location, 
then set said stored count value equal 1 ; other- 
wise if comparison is equal, check for said first 30 
sequence number greater by 1 than said stored 
second sequence number whereby increment 
said count value by 1, otherwise set said count 
value equal 1 ; and 

(d) checking if said count value is greater or 35 
equal to three, whereby store said first 
sequence number into said sequence number 
history FIFO memory, then set said second 
sequence number memory location equal to 
said first sequence number value and await a 40 
subsequent message, otherwise set said sec- 
ond sequence number memory location equal 

to said first sequence number value and await 
a subsequent message. 

45 

14. A method, as defined in Claim 10, whereby estab- 
lishing said second resynchronization process 
results from comparing said first sequence number 
with said second sequence number stored in said 
receiver and determining that a relationship exists so 
according to the following equation: 

16 > =SQN1 , SQN2 

where 55 

SQN1 is said first sequence number, and 
SQN2 is said second sequence number. 
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15. A method, as defined in Claim 14, whereby: said 
second resynchronization process comprises stor- 
ing said first sequence number into memory loca- 
tion of said second sequence number, 
authenticating said first message, storing said first 
sequence number into said sequence number his- 
tory memory, and awaiting a subsequent message. 

16. A method, as defined in Claim 10. whereby: estab- 
lishing said third resynchronization process results 
from comparing said first sequence number with 
said second sequence number stored in said 
receiver and determining that a relationship exists 
according to the following equation: 

SQN1 > SQN2 + K 

where 

SQN1 is said first sequence number, 
SQN2 is said second sequence number, and 
K is a binary value constant 

17. A method, as described in Claim 16, whereby: said 
third resynchronization process comprises: 

(a) setting number of message cycles value 
equal 2 to be received for said resynchroniza- 
tion process to be complete; 

(b) comparing said first function code with said 
stored second function code, whereby if not 
equal store said first function code value into 
said second function code memory location, 
then set said stored count value equal 1 ; other- 
wise if comparison is equal, check for said first 
sequence number greater by 1 than said stored 
second sequence number whereby increment 
said count value by 1 , otherwise set said count 
value equal 1 ; 

(c) comparing said stored count value with said 
message cycle value whereby if not equal store 
said first sequence number and said authenti- 
cator value in said verification memory indexed 
by said count value, otherwise if equal, com- 
pare said first sequence number with values 
stored in said sequence number history FIFO 
for match with previously stored said first 
sequence number values and if no match then 
authenticate all said verification memory val- 
ues, perform said function, set said count value 
equal 1, set said second sequence number 
memory location equal to said first sequence 
number value, and await a subsequent mes- 
sage, whereas if match between said first 
sequence number value with values stored in 
said sequence number history FIFO, then set 
said second sequence number memory loca- 
tion equal to said first sequence number value 
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and await next said message; and 

(d) repeating steps (a) through (c) until said 

receiver is resychronized with said transmitter. 

18. A method, as defined in Claim 10. whereby: estab- 5 
lishing said fourth resynchronization process 
results from comparing said lirst sequence number 
with said second sequence number stored in said 
receiver and determining that a relationship exists 
according to the following equation: 10 

16 < SQN1 < SQN2 

where 

75 

SQN1 is said first sequence number, and 
SQN2 is said second sequence number. 

19. A method, as defined in Claim 18, whereby: said 
fourth ^synchronization process comprises: 20 

(a) setting number of message cycles value 
equal 3 to be received for said resynchroniza- 
tion process to be complete; 

(b) comparing said first function code with said 25 
stored second function code, whereby if not 
equal store said first function code value into 
said second function code memory location, 
then set said stored count value equal 1 ; other- 
wise if comparison is equal, check for said first 30 
sequence number greater by 1 than said stored 
second sequence number whereby increment 
said count value by 1 , otherwise set said count 
value equal 1 ; 

(c) comparing said stored count value with said 35 
message cycle value whereby if not equal store 
said first sequence number and said authenti- 
cator value in said verification memory indexed 

by said count value, otherwise if equal, com- 
pare said rust sequence number with values 40 
stored in said sequence number history FIFO 
for match with previously stored said first 
sequence number values and if no match then 
authenticate all said verification memory val- 
ues, perform said function, set said count value 45 
equal 1. set said second sequence number 
memory location equal to said first sequence 
number value, and await next said message, 
whereas if match between said first sequence 
number value with value stored in said so 
sequence number history FIFO, then set said 
second sequence number memory location 
equal to said first sequence number value and 
await a subsequent message; and 

(d) repeating steps (a) through (c) until said 55 
receiver is resynchronized with said transmit- 
ter. 
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